Sharepoint 2010 : Optimizing Outside of SQL Server

1. Disk Storage Options

The location of your content is extremely important to recoverability, availability, and performance. The placement of your data files, log files, and even the Tempdb database can have a significant impact on SharePoint’s performance and availability. For instance, you should store your databases on a RAID implementation; if that isn’t possible, you should store your transaction log files (.ldf) and your data files (.mdf and .ndf) on separate physical drives for recoverability and better performance. Furthermore, these files should be on a separate drive from your operating system, which will help reduce contention.

Table 1 provides some recommended RAID implementations and I/O requests that should be targeted when you are planning your SharePoint and SQL Server integration.

Note:

MORE INFO There is an excellent best practices article written by Microsoft that goes into great depth regarding SharePoint storage. This paper can be viewed at http://msdn.microsoft.com/en-us/library/dd758814.aspx.

2. NTFS Allocation Unit Size

All file systems that Windows operating systems use to organize the hard disk are based on cluster (allocation unit) size. The cluster size is defined when you format your drive. The cluster size represents the smallest amount of disk space that can be allocated to hold a file. The smaller the cluster size, the more efficiently your disk stores information. However, when formatting the partition that will be storing your SQL Server data files, you should use a 64-kilobyte (KB) allocation unit size for your data, transaction logs, and Tempdb databases. SQL Server uses Extents to store data, which are groups of eight 8-KB pages that are physically contiguous to each other for a total of 64 KB. By doing this, it reduces the chances of I/Os that span multiple NTFS allocations, which could result in split or multiple I/Os required to retrieve your SQL data. Your performance improvement can be as much as 30 percent when using 64-KB allocation units.

Note:

Be aware that using allocation unit sizes greater than 4 KB results in the loss of the use of NTFS compression on the volume.

Run the chkdsk command to determine what your current allocation unit size is. For example, if you want to run this command on your root drive, you would type the following at the command prompt:

chkdsk c:

It will take a few moments to run, but it will then return lines of information about your disk drive. One line of information is the allocation unit in bytes, as shown here.

4096 bytes in each allocation unit.

If you divide 4096 by 1024, you will see that your cluster size is 4 KB. Whatever number is returned in the chkdsk information as the allocation unit size, divide it by 1024 to determine the actual cluster size. To increase the cluster size, you can issue the following format command.

format E: /Q /FS:NTFS /A:64K /V:Data1

Following is an explanation of what each parameter used with the previous format command means.

• E: Drive letter to format

• /Q Quick format

• /FS:NTFS File system (FAT or NTFS)

• /A:64K Allocation unit size

• /V:Data1 Volume label

NTFS supports 512, 1024, 2048, 4096, 8192, 16-KB, 32-KB, and 64-KB allocation unit sizes. However, NTFS compression is not supported for allocation units above 4096.

Note:

Issuing a format command erases all existing data and creates a data-free drive, as if you just purchased it. Be sure to copy all data to another drive before issuing the format command.

3. Monitoring SQL I/O with SQLIO.exe

SQLIO.exe is a tool provided by Microsoft that can be used to determine the I/O capacity of any storage configuration. You can use it to get an understanding of the performance behavior for your disk storage subsystem. Although it contains SQL in the file name, it is not limited to testing performance for SQL Server—it is more about measuring your disk storage I/O performance. There is a sample script file provided that you can modify to define the benchmark scenario you are testing. You must download SQLIO first, which you can do by visiting http://go.microsoft.com/fwlink/?LinkId=115176.

Note:

SQLIO is a free tool that is provided “as is,” and there is no support offered for any problems encountered when using the tool.

You can use SQLIO to test a storage configuration, but when you do so, you need to test each volume individually and then add volumes until all volumes are tested together. This means that when testing a large number of volumes, there are several combinations. In these cases, focus on scalability as the number of volumes included in the test is increased (1, 2, 4, 8, and so on). Testing the volumes in this manner enables you to determine if there are any problems with a specific volume and if the expected cumulative throughput is reached with that particular storage configuration. SQLIO will return and summarize certain performance data during the test you run. When running the test, you can redirect the output to a text file to capture the performance information for later review.

Note:

MORE INFO For a complete set of the options available in SQLIO, see the Readme.txt file associated with the tool or run SQLIO.exe -?

These additional optimization options can be helpful when you want to really fine-tune your SharePoint SQL Server environment. If you are considering making these kinds of modifications, be sure to back up all your SQL Server content in case there is a problem.

Note:

MORE INFO For additional information on disk partition alignment, go to http://msdn.microsoft.com/en-us/library/dd758814.aspx.